home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19981211-19990422
/
000025_news@newsmaster….columbia.edu _Fri Dec 18 11:47:43 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1999-04-21
|
4KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA29638
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 18 Dec 1998 11:47:42 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA29085
for kermit.misc@watsun; Fri, 18 Dec 1998 11:47:42 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: receiving straight binary
Date: 18 Dec 1998 16:47:41 GMT
Organization: Columbia University
Lines: 61
Message-ID: <75e0vd$74n$1@apakabar.cc.columbia.edu>
References: <gerlachF4602I.IDE@netcom.com> <75dsph$4i1$1@apakabar.cc.columbia.edu> <gerlachF46656.2yF@netcom.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9657
In article <gerlachF46656.2yF@netcom.com>,
Matthew H. Gerlach <gerlach@netcom.com> wrote:
: In article <75dsph$4i1$1@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
: >In article <gerlachF4602I.IDE@netcom.com>,
: >Matthew H. Gerlach <gerlach@netcom.com> wrote:
: >: I have a device that spits out raw binary serial data, and I want it to
: >: go to a harddrive. I'm using 6.1.193 Beta.05 on a Solaris machine. What
: >: I did was write a small program that reads stdin and writes it to a file.
: >: I then used the ckermit "redirect" command to run my program attaching
: >: the serial input stream to my program's stdin.
: >:
: >: I'm sure there is a better way to do this, but I'm not sure what that
: >: better way is. I have written scripts using the "input" command that
: >: does the same thing for ascii text, but I'm not sure it would work too
: >: well in the this case.
: >:
: >There's no reason why it shouldn't:
: >
: > set line /dev/tty0 ; or whatever
: > set speed 19200 ; or whatever
: > set parity none
: > set flow rts/cts ; or none -- not xon/xoff
: > set session-log binary
: > set terminal byte 8
: > set terminal character-set transparent
: > log session
: > input 9999 termination-sequence
: > close session
: >
: >The trick is to know when to stop logging, but you must have had some
: >criterion in your stdin/stdout program so you should be able to use the
: >same one here.
: >
: >- Frank
:
: The termination criteria is the trick. Currently, my stdin/stdout program
: has no "stopping criteria". It stops when I signal it. From the "input"
: command's point of view, the data stream is random; so there is no
: pattern to "look for". I just want to "input" the bytes and log them.
: For the record, the data stream is a Mu-law encoded audio stream.
:
: Thinking about this more. What I have is a burst of data coming out of the
: device. So a convenient script would wait a certain amount of time
: for anything to come over the wire, log it, and when there is large pause
: in the data stream, say a second or so, it would stop.
:
: Looking at the "input" command in the manual some more, if I just give
: it a timeout and no text it will wait for any single character. I suppose
: this would work, but I'm running at 115k, and it seems "input"ing
: single characters might be rather expensive processing-wise.
:
: Matthew
:
Yes, that would be expensive.
How about this:
SET INPUT SILENCE 60 ; Make INPUT time out after 60 seconds of silence
INPUT 9999 string-that-will-never-come
- Frank